Within the prior art, software systems are often touted as being flexible and easily adaptable. In general, this is only true for small software programs and controlling non-real time events. For large software systems controlling real time processes, such as telephone switching processes, these systems are not particularly flexible. The reason for this inflexibility is that the systems are quite large, each portion of the system is time critical, and reliability is of the utmost importance. It is commonplace for software that runs on a personal computer to use a message when it is necessary for the user to reboot the system or for the system to automatically reboot itself. However, in real time systems, such as telecommunication systems, the software must run unattended and maintain reliability through a variety of conditions. The process that is gone through to assure this reliability and speed of real time systems makes these systems expensive to develop and very prone to fatal errors if small changes are made within the software. In addition, real time systems of this type are developed over many years, beginning with a common base which advances with further development. It is not uncommon that the developers of the real time system are no longer employed or working on the systems. Consequently, the people that would be making the modifications are not aware of all of the considerations that were used to cause certain sections of the program to be written in a certain way.
In addition, a program written ten or fifteen years ago may now be utilized on modern hardware. The new hardware often will be packaged in a different manner than the hardware for which the software system was originally developed. The older hardware may well have had particular requirements that caused the software to be written in a certain way. However, new hardware and more importantly new packaging techniques have obsoleted the original hardware. The result is that the new hardware must still conform to what the software believes the hardware should appear to be. This is particularly true in the field of business telecommunication systems where the original systems of ten or fifteen years ago were placed in large cabinets that were well structured with respect to the card carriers, with each carrier having an unique physical address. As technology has developed, the original carriers have been downsized and are no longer mounted in cabinets; rather, the modules may be individually mounted on walls or placed in racks in random order. However, the software systems that are utilized to control this new hardware configuration still anticipates that it is like the original hardware design.
To overcome this problem, designers have used the physical address information to identify one module from another. Also, it is necessary to visually identify these different modules so that service personnel know which module is which. Unfortunately, prior art techniques identify the physical hardware address of a carrier or module through the use of dip switches or wire straps that are normally positioned on the back of the module or carrier; whereas, the visual identification of that module is placed on the front of the module. Interestingly enough, this separation of the physical address from the visual address causes a large number of problems in the field. In addition, the modules are interchangeable and are only uniquely specified by the cards that are placed in them, but the cards assume addresses based on the physical address of the module. The card will transmit these assumed addresses to the central controller. In turn, the central controller bases control messages sent to the cards on the assumed addresses.